Object oriented programming systems and processes, also referred to as "object oriented computing environments", have been the subject of much investigation and interest in state of the art data processing environments. As is well known to those having skill in the art, object oriented computing environments are composed of a large number of "objects". An object is a data structure, also referred to as a frame, and a set of operations or functions, also referred to as "methods", that can access that data structure. The frame has many "slots" each of which contains an "attribute" of the data in the slot. The attribute may be a primitive (such as an integer or string) or an object reference (OREF) which is a pointer to another object.
Each defined object will usually be manifested in a number of "instances". Each instance contains the particular data structure for a particular example of the object. In an object oriented computing environment, the data is processed by requesting an object to perform one of its methods by sending the object a "message". The receiving object responds to the message by choosing the method that implements the message name, executing this method on the named instance, and returning control to calling high level routine along with the results of the method.
Object oriented programming systems may be used as database management systems which are capable of operating upon a large database, and which are expandable and adaptable. In an object oriented database management system, the data in the database is organized and encapsulated in terms of objects, with the instances of the objects being the data in the database. Similarly, the database manager may be organized as a set of objects, with database management operations being performed by sending messages from one object to another. The target object performs the requested action on its attributes using its methods.
A major concern of object oriented database management systems is preserving data integrity. Preservation of data integrity is difficult as the size and complexity of the database increases. Moreover, for a very large database it is desirable to have multiple tasks performed concurrently, thereby further impacting data integrity.
A major advancement in preserving data integrity of object oriented computing environments is the "unit of work". The unit of work is an object class including multiple unit of work objects and multiple unit of work instances. The unit of work allows the object oriented database system to manipulate, update, allocate and discard memory in terms of sets of objects and operations upon objects, rather than by manipulating memory pointers as in traditional languages like C and Pascal.
The unit of work and its operation are described in detail in Application Ser. No. 07/425,607 to Abraham et al., filed Oct. 23, 1989, entitled Unit of Work for Preserving Data Integrity of a Database, and assigned to the assignee of the present invention, the disclosure of which is hereby incorporated herein by reference. As described therein, the database manager includes a unit of work manager. The unit of work manager assigns a unit of work instance to each task to be performed by copying the objects which are to be processed during a database task into a unit of work instance. A version of the object instances in the unit of work instance, referred to as a unit of work level, is created for each step in the task. Each unit of work level for a task includes a copy of the data objects which are to be modified by the task. Each step in the task is controlled to modify the data elements in the associated unit of work level, rather than the data elements in the database itself. The unit of work class also includes associated methods for "commit", "discard", "new", "notify", "rollback", "start" and "switch". These methods allow the unit of work instance to be manipulated as a whole to ensure database integrity.
As described above, an object oriented computing environment typically includes an object management table which is used to keep track of all the objects which are currently being used. The use of the object management table in connection with the unit of work is described in application Ser. No. 07/602,442 filed Oct. 23, 1990 to Shackelford et al. entitled A Messenger and Object Manager to Implement an Object Oriented Environment, assigned to the assignee of the present invention, the disclosure of which is hereby incorporated herein by reference. The object management table is used to manage the creation of new unit of work instances and to manage the creation of new unit of work levels within a unit of work instance. Switching, commits and rollbacks of unit of work levels and instances are also managed. As described in detail in the above mentioned application, the object management table is typically a multidimensional array including four related components: an Object Management Table Main Class (OMTMC) table, an Object Management Table Unit of Work Instance Information Class (OMTUC) table, an Object Management Table Object Instance Information (OMTIC) table, and an Object Management Table Frame Information Class (OMTFC) table. Entries in these tables are controlled by the object manager to control operation of the object oriented computing environment.
Notwithstanding the improvement of the unit of work in maintaining database integrity, it is important that the unit of work instances do not interact with each other to impact database integrity. For example, the unit of work system allows a "visitor" object, which is a copy of the object in the current unit of work, which is materialized from the other unit of work in which it resides at the time a message is sent, rather than being materialized from the database. However, the ability to produce visitor objects may cause objects to be placed in a unit of work from another unit of work rather than from the database. Data integrity may be impacted since the unit of work may include intermediate data which has been changed by the database management system. On the other hand, there are many instances where a unit of work legitimately can obtain a visitor object from another unit of work.
Similarly, on some occasions it may be desirable to allow persistent objects in a unit of work level to be modified, changed or deleted, but on other occasions it may be undesirable. As is well known to those having skill in the art, object oriented computing environments include persistent objects which must survive run time and which are stored in nonvolatile storage. If a persistent object is unknowingly changed, database integrity can be impacted. Accordingly, there is a need for a boundary control mechanism for units of work in an object oriented computing environment.